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(54) Data processing method, apparatus and system for encrypted data 



transfer 



(57) A data processing apparatus includes an 
encrypting apparatus for encrypting data in units of an 
encryption block having a predetermined data length. A 
processing apparatus Is also provided for performing 
predetermined processing on data in units of a process- 
ing block having a data length of a whole multiple of the 
predetermined length of the encryption block. A control- 



ler is also provided for writing the encrypted data in a 
storage medium so that the data positioned in the same 
encryption block is also positioned In the same process- 
ing block. The controller also reads the data from the 
storage means in units of the processing block when the 
data is to be read out. 
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Description 

[0001] The present invention relates to a data 
processing metliod and apparatus for encrypting and 
decrypting digital data. s 
[0002] In order to prevent Illicit use. data files that 
contain copyrighted material can be encrypted prior to 
storage. For example, it is sometimes necessary for 
storage and/or editing to divide an audio track corre- 
sponding to a sequence of songs into related data mod- io 
ules (or parts) whose smaller size is more conducive to 
various storage mediums. Because the various parts of 
a track may not be stored sequentially, each track must 
contain information defining the parts of which it is com- 
prised. Othenwise, parts may become lost during trans- w 
fers or editing. Therefore, any changes to the parts must 
be recognized at the track level. In addition, each part is 
comprised of a sequence of data blocks (clusters). Such 
audio tracks are often encrypted to prevent unauthor- 
ized use and copying of the music. 20 
[0003] In order to make unauthorized use of the 
data more difficult the encryption process assigns a 
content key to each track and a part key to each part 
(module). The content keys and part keys are then proc- 
essed into block keys for encrypting the data at the 25 
block level. 

[0004] When data encrypted in this manner is 
edited, encrypted parts may end up belonging to a new 
track that was encrypted with different block keys. 
Because the block keys depend on the track keys and so 
part keys, any changes in the content of a track requires 
the data be first decrypted using the old track and part 
keys, then re-encrypted with the new track and part 
keys. Otherwise, tracks encrypted with a mix of keys will 
result and parts could become lost. This would make 35 
subsequent use of the data impossible. 
[0005] This requirement that the previously 
encrypted track data be decrypted and then re- 
encrypted whenever editing is performed creates a tre- 
mendous processing burden. Currently, this burden 40 
results in processing times that make such encryption 
impractical. 

[0006] Various respective aspects and features of 
the invention are defined in the appended claims. 
[0007] Embodiments of the present invention can 45 
alleviate the related art's above discussed processing 
problem by providing a data processing method and 
apparatus capable of shortening the processing time 
required when editing or the like is performed. 
[0008] Embodiments of the invention can provide so 
an improved method, apparatus and system for record- 
ing and reproducing encrypted data in which data is 
encrypted in units of an encryption block of a predeter- 
mined data length and predetermined processing is 
performed on the encrypted data in units of a process- ss 
ing block having a data length of a whole multiple of the 
encryption block. 

[0009] Embodiments of the invention can provide 



an improved method, apparatus and system for record- 
ing and reproducing encrypted data in which data is 
encrypted in units of an encryption block of a predeter- 
mined data length and predetermined processing is 
performed on the encrypted data in units of a process- 
ing block having a data length of a whole multiple of the 
encryption block, and wherein the encrypted data is 
written in a storage medium so that all data positioned in 
the same encryption block Is also positioned in the 
same processing block. 

[0010] Still other objects and advantages of the 
invention will in part be obvious and will in part be 
apparent from the specification and the drawings. 
[0011] In accordance with the invention, a data 
processing apparatus is provided comprising an 
encrypting apparatus for encrypting data in units of an 
encryption block of a predetermined data length and a 
processing apparatus for performing predetermined 
processing on data in units of a processing block having 
a data length of a whole multiple of the encryption block. 
A storage medium for storing the encrypted data and a 
control apparatus for writing the encrypted data to the 
storage medium are provided. Thus, data positioned in 
the same encryption block is also positioned in the 
same processing block. Data read from the storage 
medium during processing is read in units of the 
processing block, and therefore also reads complete 
encryption blocks. 

[0012] Further, in the data processing apparatus of 
the invention, the control apparatus preferably inserts 
data to adjust the data length of the processing block so 
that the data length of the processing block becomes a 
whole multiple of the data length of an encryption block. 
[0013] Further, in the data processing apparatus of 
the invention, the encrypting apparatus preferably per- 
forms encryption processing using the encryption block 
to be encrypted and a cipher text obtained from the 
encryption of the encryption block immediately before 
the encryption block to be encrypted. 
[0014] Further, in the data processing apparatus of 
the invention, the control apparatus preferably manages 
the encrypted data stored in the storage means in 
accordance with a data storage cluster containing one 
or more processing blocks and initial values used when 
encrypting an encryption block encrypted in a process- 
ing block. 

[0015] Further, in the data processing apparatus of 
the invention, the control means preferably stores one 
or more processing blocks at consecutive addresses of 
the storage medium in the order of encryption, stores 
one or more encryption blocks in the processing blocks 
at consecutive addresses of the storage medium In the 
order of encryption, and stores the initial values at an 
address immediately before the address of the storage 
medium at which the encryption block first encrypted in 
the processing block of the cluster is stored. 
[0016] Further, the data processing system of the 
invention comprises a data processing system for input- 



2 



3 



EP1 037 209 A2 



4 



ting and outputting data while performing mutual identi- 
fication between a storage apparatus and a data 
processing apparatus. The storage apparatus com- 
prises a first mutual identification processing apparatus 
for performing processing for mutual Identification with 5 
the data processing apparatus. A storage medium for 
storing the data, and a first control apparatus for allow- 
ing the input and output of data between the data 
processing apparatus and the storage medium when 
the data processing apparatus is recognized to be a 10 
legitimate party by the processing for mutual identifica- 
tion are also provided. The data processing system fur- 
ther comprises a second mutual identification 
processing apparatus for performing processing for 
mutual identification with the storage medium. An 75 
encrypting apparatus for encrypting data In units of an 
encryption block of a predetermined data length and a 
processing apparatus for performing predetermined 
processing on data in units of a processing block having 
a data length of a whole multiple of the encryption block 20 
are also provided. A second control apparatus for per- 
forming at least one of write processing and read 
processing when the data processing apparatus is rec- 
ognized to be a legitimate party by the processing for 
mutual identification, writing the encrypted data in the 2s 
storage medium so that data positioned in one encryp- 
tion block is also positioned in the same processing 
block during write processing, and reading the data 
from the storage medium in units of the processing 
block during read processing. 30 

[0017] Further, the data processing method of the 
invention comprises enaypting data in units of an 
encryption block of a predetermined data length and 
performing predetermined processing on data in units 
of a processing block having a data length of a whole 35 
multiple of the encryption block. The encrypted data is 
written in a storage medium so that all data positioned in 
the same encryption block is also positioned in the 
same processing block. The method thus allouvs for 
reading the data from the storage medium in units of a 4o 
processing block and therefore also in units that is a 
multiple of encryption blocks. 
[0018] The invention accordingly comprises the 
several steps and the relation of one or more of such 
steps with respect to each of tiie others, and the appa- 45 
ratus embodying features of construction, comt)inations 
of elements and arrangement of parts that are adapted 
to effect such steps, all as exemplified in the following 
detailed disclosure, and the scope of the invention will 
be indicated in the claims. so 
[0019] The invention will now be described by way 
of example with reference to the accompanying draw- 
ings, throughout which like parts are referred to by like 
references, and in which: 

55 

Figure 1 Illustrates the overall system configuration 
of the audio system constructed in accordance with 
the present invention; 



Figure 2 depicts the internal structure of the porta- 
ble storage device and portable player shown in 
Figure 1 

Rgure 3 depicts data stored In a storage unit of the 
portable storage device shown in Figure 2; 
Figure 4 depicts data stored in a flash memory of 
the portable device shown in Figure 2; 
Figure 5 deplete a data structure of a reproduction 
management file PBLIST.MSF that is a sub direc- 
tory stored in the portable storage device shown in 
Figure 2; 

Figure 6 depicts the data structure of an ATRAC3 
data file divided into blocks of a predetermined unit 
length, and including an attribute header; 
Figure 7 depicts the overall data structure of a 
reproduction management file PBLIST; 
Figure 8 depicts the detailed data structure of the 
reproduction management file PBLIST including: a 
header portion, a main data portion, and an addi- 
tional information data portion; 
Rgure 9 depicts the structure of the data stored in 
the storage unit of the portable player shown in Fig- 
ure 2; 

Figure 10 depicts tiie detailed data structure of an 
ATRAC3 data file; 

Rgure 1 1 depicts tiie data structure of an upper 
portion of the attribute header of an ATRAC3 data 

file; 

Figure 12 depicts the data structure of a middle por- 
tion of the attribute header of an ATRAC3 data file; 
Figure 13 is a con-elation table for correlating record 
modes, record time, and other information; 
Figure 14 is a table showing copy control states; 
Figure 15 depicts the data structure of a lower por- 
tion of the attribute header of an ATRAC3 data file; 
Figure 16 depicts the data structure of a header of 
a data block of an ATRAC3 data file; 
Rgure 1 7 depicts tiie data stored in the storage unit 
of the portable player shown in Figure 2; 
Figure 18 explains the CBC mode of encryption in 
the encrypting/decrypting unit of the portable player 
shown in Figure 2; 

Figure 19 explains the CBC mode of decryption in 
the encrypting/decrypting unit of the portable player 
shown in Figure 2; 

Rgure 20 is a flow chart for explaining a write oper- 
ation from the portable player to tiie portable stor- 
age device shown in Figure 2; 
Rgure 21 depicts the selection of the identification 
key data IKj by tiie mutual identification unit shown 
in Figure 2; 

Figure 22 explains a mutual identification process 
between tiie portable storage device and the porta- 
ble player shown in Figure 2; 
Figure 23 explains the creation of the session key 
data Sek; 

Figure 24 explains the write operation of audio data 
from the portable player to the portable storage 
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device shown in Figure 2; 

Figure 25 is a flow chart explaining a read operation 
from the portable storage device to the portable 
player shown in Rgure 2; 

Figure 26 explains the read operation of audio data s 
from the portable storage device to the portable 
player shown in Figure 2; 

Figure 27 explains the divisional editing of the track 
data file by the editing module of the portable 
player; io 
Figure 28 depicts the data in the cluster CL(2) of 
track(1) after the divisional editing shown in Figure 
27; 

Figure 29 depicts the data in the cluster CL(0) of 
traGk(2) after the divisional editing shown in Figure 75 
27; 

Figure 30 is a flow chart for creating the track key 
data and the part key data of a new track data file at 
the divisional editing step by the editing module of 
the portable player shown in Figure 2; 20 
Rgure 31 explains the coupled editing of track data 
files by the editing module of the portable player 
shown in Figure 2; and 

Figure 32 is a flow chart for creating the part key 
data of parts (1) and (2) of track data file (3) newly 2s 
created in the editing module of the portable player 
shown in Rgure 2; 



[0020] Figure 1 is a view of the system configura- 
tion of an audio system 1 constructed in accordance 30 
with the present invention. The audio system 1 has for 
example a computer 2, a portable storage device 3, a 
portable player 4, a CD-ROM drive 6, and a CD player 
7. Audio system 1 corresponds to the data processing 
system of the present invention, portable storage device 35 
3 corresponds to the storage device of the present 
invention, and portable player 4 con-esponds to the data 
processing apparatus of the present invention. 
[0021 ] In the present embodiment, the first key data 
of the present invention corresponds to the content key 40 
data CK , the second key data corresponds to the part 
key data PK, the third key data corresponds to the tem- 
porary key data TMK, the fourth key data con-esponds 
to the block seed data BS. and the fifth key data corre- 
sponds to the block key data. 45 
[0022] Figure 2 is a view of the internal configura- 
tion of portable storage device 3 and portable player 4 
shown in Figure 1 . In the present embodiment, the mod- 
ule use key data calculating means of the present inven- 
tion corresponds to a key creation/key processing unit so 
62 shown in Figure 2, the encrypting means corre- 
sponds to an encrypting/decrypting unit 64, and the key 
data processing means corresponds to an editing mod- 
ule 44. 

55 

Computer 2 

[0023] Computer 2 is connected to a network 5, 



receives audio data (track data) from a host computer 
(not shown) of a service provider who provkJes EMD 
(Electronic Music Distribution) or other services via net- 
work 5, decrypts the received audio data according to 
need, and outputs the same to portable player 4. Com- 
puter 2 exchanges identifk;ation, charging, and other 
necessary information with the host computer of the 
service provkJer when receiving content data. Compu- 
ter 2 can also transfer audio data input from CD-ROM 
drive 6 to portable player 4. 

Portable Storage Device 3 

[0024] As is further shown in Figure 2, portable 
storage device 3 houses a built In rewritable semicon- 
ductor memory such as a flash memory 34, commer- 
cially available from Sony Corporation under the 
trademark Memory Stick. Portable storage device 3 also 
has a main control module 31, a communication inter- 
face 32. a control module 33, and a flash memory man- 
agement module 35. 

Control Module 33 

[0025] Control module 33 is a single chip integrated 
circuit with a multi-layer structure used exclusively for 
encryption. Internal memory cells are sandwiched by 
dummy layers such as aluminum layers. Further, control 
module 33 has a narrow range of operating voltage or 
operating frequency and is tamper resistant so that any 
stored data cannot be illicitly read from the outside. 
[0026] As shown in Figure 2, control nxxilule 33 
contains a random number generation unit 50, a stor- 
age unit 51 , a key creation/processing unit 52. a mutual 
identification unit 53, an encrypting/decrypting unit 54, 
and a control unit 55. Random number generation unit 
50 generates a 64 bit (8-byte) random number upon 
receiving a random number generation instruction. Stor- 
age unit 51 may include an EEPROM (electrically eras- 
able programmable read only memory) or other 
nonvolatile memory and stores key data and other vari- 
ous data required for identification. 
[0027] Figure 3 depicts the data stored in storage 
unit 51 . This stored data includes identification key data 
IKo to IK31, device identification data ID^ and storage 
use key data Skm. 

[0028] The identification key data IKq to IK31 are 
key data used when portable storage device 3 performs 
a mutual identification process with portable player 4. 
One identification key from among the Identification key 
data IKq to IK31 is selected at random whenever the 
mutual Identification process is performed. Note that the 
identification key data IKq to IK31 and the storage use 
key data Skm cannot be read from outside of portable 
storage device 3. The device identification data (D^ is 
Identification data uniquely attached to each portable 
storage device 3 and is read out when portable storage 
device 3 performs the mutual identification process witii 
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portable player 4. The storage use key data Skm is used 
when encrypting the content key data CK and storing 
the same in flash memory 34 as will be mentioned later. 

[0029] Key creation/processing unit 52 creates the 
key data by performing a MAC (message authentication s 
code) operation and/or other various operations as 
defined by the ISO/IEC9797 standard. Currently, the 
MAC operation uses a "block cipher afgorithm** defined 
in FIPSPUB46-2 as the DES (data encryption stand- 
ard). The MAC operation is a one-way Hash function in io 
which data having an arbitrary length is compressed to 
a fixed length, and a function value is determined by a 
secret key. 

[0030] Mutual identification unit 53 performs the 
mutual identification process with portable player 4 is 
before receiving audio data from portable player 4 and 
writing the same into flash memory 34. Mutual identifi- 
cation unit 53 performs the mutual identification process 
with portable player 4 before reading audio data from 
flash memory 34 and outputting the same to portable 20 
player 4. Mutual Identification unit 53 also performs a 
MAC operation as part of the mutual identification proc- 
ess. The data stored in storage unit 51 is used for per- 
forming the mutual identification process. 
[0031] Encrypting/decrypting unit 54 performs the 2S 
encryption and decryption using one of the DES, IDEA, 
MISTY, or other block cipher algorithms. The mode 
used is an ECB (electronic code book) mode and a CBC 
(cipher block chaining) mode as prescribed in FIPS 
PUB81 "DES MODES OF OPERATION". In block 30 
encryption/decryption in accordance with the ECB and 
CBC modes, the designated data is 
encrypted/decrypted by using designated key data. 
Control unit 55 centrally controls processing by random 
number generation unit 50, storage unit 51. key crea- 3s 
tion/^rocessing unit 52, mutual identification unit 53, 
and encrypting/decrypting unit 54. 

Flash Memory 34 

40 

[0032] Once portable player 4 is recognized as a 
legitimate party by the mutual identification unit 53, the 
audio data input from player 4 is written into flash mem- 
ory 34. Conversely, the audio data can be output from 
flash memory 34 to portable player 4 once portable 45 
player 4 is recognized as a legitimate party by mutual 
identification unit 53. Flash memory 34 has a storage 
capacity of 32 Mbytes. 

[0033] As shown in Figure 4, flash memory 34 
stores a reproduction management file 100. followed by so 
a series of track data files IOIq, 101 1, IOI2, and IOI3. 
Reproduction management file 100 contains data for 
managing reproduction of track data files IOIq to IQI3. 
Track data files 1 01 1. to 101 3 contain the actual track 
data (audio data). In the present embodiment, track ss 
data is used to mean one song's worth of audio data. 
[0034] Figures 5 and 6 show how a reproduction 
management file Is used in implementing a sample file 



format. ATRAC3 (Adaptive Transform Acoustic Coding) 
is a highly efficient encoding format for audio data. Fig- 
ure 5 shows the structure of a reproduction manage- 
ment file. Figure 6 shows the file structure of an 
ATRAC3 data file. An ATRAC3 data file is composed of 
an attribute header and an encrypted music data area 
for each music program. Both the reproduction manage- 
ment file and the ATRAC3 attribute header have a fixed 
file length of 16 KB (one block). 

[0035] The reproduction management file shown in 
Figure 5 is composed of a header, a memory card name 
NM-1S (for one byte code), a memory card name NM2- 
S (for two byte code), a program reproduction sequence 
table TRKTBL, and an additional information area INF- 
S. The attribute header (shown in Figure 6) at the begin- 
ning of the data file is composed of a header, a program 
name NM1 (for one byte code), a program name NM2 
(for two byte code), track information TRKINF (such as 
track key information), part information PRTINF, and an 
additional track information area INF The header con- 
tains information on the total number of parts, the track 
name, the size of the additional information area, and so 
forth. 

[0036] The attribute header is followed by ATRAC3 
music data. The music data Is block-segmented every 
16 KB, each block starting with a header. TTie header 
contains an initial value for decrypting encrypted data. 
Only the music data of an ATRAC3 data file is 
encrypted. Thus, the reproduction management file, the 
header, and so forth are not encrypted. 
[0037] Figure 7 is a schematic diagram showing the 
detailed data structure of a reproduction management 
file. Figure 8 shows a header portion and the remaining 
portion of the reproduction management file of Rgure 7. 
The reproduction management file contains a 32 byte 
header, a name NM1-S area (256 bytes) (for tiie mem- 
ory card), a name NM2-S area (512 bytes), a contents 
key area, a MAC area, an S-YMDhms area, a reproduc- 
tion sequence management table TRKTBL area (800 
bytes), a memory card additional information INF-S 
area (14720 bytes), and a redundant header informa- 
tion area. The start positions for each of tiiese areas 
within the reproduction management file are predefined. 
[0038] As shown in Figure 8, tfie first 32 bytes of 
(0x0000) to (0x0010) are used for the header. Within the 
file, 1 6-byte areas are referred to as slots. The header is 
placed in the first and second slots indicated at 0x0000 
and 0x0010. The area denoted as "Reserved" is an 
undefined area. Normally, a null (0x00) is written in 
reserved areas. However, even if data is written to a 
reserved area, the data is ignored. The reserved areas 
are intended for use in future revisions of the file format. 
Option areas, when not used, are treated as reserved 
areas. Additionally, the reproduction management file 
header contains the following defined areas: 

= BLKID-TLO (4 bytes) 
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Meaning: BLOCKID FILE ID 

Function: Identifies the top of the reproduction 
management file. 

Value: Fixed value = TL = 0" (for example. 
0x544C2D30) 5 

ly/ICode (2 bytes) 

Meaning: MAKER CODE 

Function: Identifies the maker and model of the io 
recorder/player 

Value: High-order 10 bits (Maker code): low- 
order 6 bits (model code). 

REVISION (4 bytes) w 

Meaning: Number of rewrite times of PBLIST 
Function: Increments whenever the reproduc- 
tion management file is rewritten. 
Value: Starts at 0 and increments by 1 . 20 

SY1C+L(2bytes) 

Meaning: Attribute of name (one byte code) of 
memory card written in NM 1 -S area 25 
Function: Represents the character code and 
the language code as one byte code. 
Value: Character code (C): High-order one byte 

00: Non-character code, binary number 30 
01: ASCII (American Standard Code for 
Information Interchange) 
02:ASCII+KANA 
03: Modified 8859-1 

81:MS-JIS 35 

82: KSC 5601-1989 

83: GB (Great Britain) 2312-80 

90: S-JIS (Japanese Industrial Standards) 

(for Voice) 

Language code (L): Low-order one byte 40 
identifies the language based on EBU 
Tech 3258 standard. 
00: Not set 
08: German 

09: English - 45 
OA: Spanish 
OF: French 
15: Italian 
ID: Dutch 

65: Korean so 
69: Japanese 

75: Chinese When data is not recorded, 
this area is all 0. 

SIVI2C+L (2 bytes) 55 

Meaning: Attribute of name of memory card in 
NM2-S area. 



Function: Represents the character code and 
the language coded as one byte code. 
Value: Same as SNIC-hL 

» SINFSIZE (2 bytes) 

Meaning: Total size of additional information of 
menrK>ry card In INF-S area. 
Function: Represents the data size as an incre- 
ment of 16 bytes. When data is not recorded, 
this area Is all 0. 

Value: Size: 0x0001 to 0x39C (924) 

= T-TRK (2 bytes) 

Meaning: TOTAL TRACK NUMBER 
Function: Represents the number of total 
tracks. 

Value: 1 to 0x0190 (Max. 400 trad^) 

When data Is recorded, this area Is all 0. 

= VerNo (2 bytes) 

Meaning: Format version number 
Function: Represents the major version 
number (high order one byte) and the minor 
version number (low order one byte). 
Value: 0x0100 (Ver 1.0) 0x0203 (Ver 2.3) 



Next, areas preceded by the header are 
described. 
=NM1-S 

Meaning: Name of memory card (as one byte 
code) 

Function: Represents the name of the memory 
card as one byte code (max. 256). At the end of 
this area, an end code (0x00) is written. The 
size is calculated from the end code. When 
data is not recorded, null (0x00) Is recorded 
from the beginning (0x0020) of this area for at 
least one byte. 

Value: Various character code 
= NM2-S 

Meaning: Name of memory card (as two byte 
code) 

Function: Represents the name of the memory 
card as two byte code (max. 512). At the end of 
this area, an end code (0x00) is written. The 
size is calculated from the end code. When 
data is not recorded, null (0x00) Is recorded 
from the beginning (0x0120) of this area for at 
least two bytes. 
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Value: Various character code 
: CONTENTS KEY 

Meaning: Value for music program. Protected s 
with MG(M) and stored. Same as CONTENTS 
KEY. 

Function: Used as a key necessary for calculat- 
ing MAC of S-YMDhms. 

Value: 0 to OxFFFFFFFFFFFFFFFF io 
MAC 

Meaning: Forged copyright information check 
value 75 
Function: Represents the value generated with 
S-YMDhms and CONTENTS KEY 
Value: 0 to OxFFFFFFFFFFFFFFFF 

S-YMDhms (4 bytes) (optional) 20 

Meaning: Year, month, day, hour, minute, and 
second recorded by the recorder/player with a 
reliable clock. 

Function: Identifies the last recorded date and 25 
time. In this case of EMD. this area Is manda- 
tory. 
Value: 

bits 25 to 31 : Year 0 to 99 (1 980 to 2079) 30 

bits 21 to 24: Month 0 to 12 

bits 16 to 24: Day 0 to 31 

bits 11 to 15: Hour 0 to 23 

bits 05 to 10: Minute 0 to 59 

bits 00 to 04: Second 0 to 29 (two second 3S 

interval) 

TRK-nnn 

Meaning: SON (sequence) number of ATRAC3 40 

data file reproduced. 

Function: Represents FNO of TRKINF. 

Value: 1 to 400 (0x190) 

When there is no track, this area is all 0. 45 

INF-S 

Meaning: Additional irrformatlon of memory 
card (for example, information with respect to so 
photos, songs, guides, etc.) 
Function: Represents variable length additional 
information with a header. A plurality of types of 
additional information may be used. Each of 
the types of additional information has an ID ss 
and a data size. Each additional information 
area including a header is composed of at least 
16 bytes and a multiple of 4 bytes. For details, 



see the following section. 

Value: Refer to the section of "Data Structure of 
Additfonal Information". 

[0039] In the last slot of the reproduction manage- 
ment file, copies off BLKID-TLO, MCode. and REVISION 
from the header are redundantly written. 
[0040] If a memory card is accidentally detached or 
the power of the recorder/player turned off while data is 
being recorded into the card, a termination error should 
be detected. As described above, a REVISION area is 
placed at the beginning and end of each block. When- 
ever data Is rewritten, the value of the REVISION area 
is incremented. If a termination error occurs in the mid- 
dle of writing a block, the value of the REVISION area at 
the beginning of the block will not match the value of the 
REVISION area at the end of the block. This discrep- 
ancy between the two REVISION areas allows termina- 
tion en-ors to be determined with a high probability. 
When such an abnormal termination is detected; an 
alarm, such as an error message, is generated. 
[0041] In addition, because the fixed value BLKID- 
TLO is written at the beginning of one block (16 KB) the 
fixed value can be used as a reference for recovering 
data. In other words, the fixed value allows the type of 
the file to be determined. Because the fixed value 
BLKID-TLO is redundantly written in the header and at 
the end of each block, reliability is secured. Alterna- 
tively, the entire reproduction management file can be 
redundantly recorded. 

[0042] Because the amount of data in an ATRAC3 
data file Is much larger than in a track information man- 
agement file, ATRAC3 data files are not redundantly 
recorded. Instead COONUMO and BLOCK SERIAL val- 
ues are used to help recover lost ATRAC3 data (as will 
be described below). In addition, one ATRAC3 data file 
may be composed of a plurality of blocks that are dis- 
persed. To identify blocks of the same file, CONNUMO is 
used and to identify the order of the blocks BLOCK 
SERIAL is used. Likewise, as noted above, a maker 
code (MCode) is redundantly recorded at the beginning 
and the end of each block, so as to identify the maker of 
a file which has been improperly recorded. 
[0043] Figure 8 also shows the structure of an addi- 
tional information area. The additional information area 
is composed of a header comprised of the following 
data, and additional variable length data: 

= INF 

Meaning: FIELD ID 

Function: Represents the beginning of the 
additional information (fixed value). 
Value: 0x69 

=ID 

Meaning: Additional information key code 
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Function: Represents the category of the addi- 
tional information. 

Value: 0 to OxFF 
= SIZE 

Meaning: Size of individual additional informa- 
tion 

Function: Represents the size of each type of 
additional information. Although the data size is 
not limited, it should be at least 16 bytes and a 
multiple of 4 bytes. The rest of the data should 
be tilled with null (0x00). 
Value: 16 to 14784 (0x39C0) 

= MCode 

Meaning: MAKER CODE 

Function: Identifies the mal<er and model of the 

recorder/player. 

Value: High-order 10 bits (maker code), low- 
order 10 bits (machine code). 

=C+L 

Meaning: Attribute of characters in data area 
starting from byte 12. 

Function: Represents the character code and 
the language code as one byte code. 
Value: Same as SNC+L 

= DATA 

Meaning: Individual additional information 
Function: Represents each type of additional 
information with variable lengtii data. Real data 
always starts from byte 12. The lengtii (size) of 
tiie real data should be at least 4 bytes and a 
multiple of 4 bytes. The rest of the data area 
should be filled with null (0x00). 
Value: Individually defined corresponding to 
the contents of each type of additional informa- 
tion. 

[0044] Next, an explanation is made of track data 
files 101o to IOI3, as shown in Figure 9. Track data file 
IOI0 comprises one part that includes five clusters 
CL{0), CL(1), CL(2), CL(3), and CL(4). The part com- 
prising track data file IOIq starts at the head of cluster 
CL(0) and ends at a sound unit SU(4) of cluster CL(4). 
[0045] Note that each of the track data files 101 1 to 
101 3 has basically the same configuration shown in Fig- 
ure 9, but the number of parts, the number of clusters, 
and the number of sound units SU contained in the dus- 
ter are independently determined and may vary 
between track data files. 

[0046] Next, the relation between music programs 
and ATRAC3 data files is described. One track is equiv- 



alent to one music program. In addition, one music pro- 
gram is composed of one ATRAC3 data (see Figure 6). 
The ATI^CS data file is recorded one cluster at a time 
into the memory card 40. Each cluster has a capacity of 
5 16 KB. Only one file is contained in each cluster. The 
minimum erasable unit of data for ttie flash memory 42 
is one block. A block is synonymous with a cluster or a 
sector. 

[0047] One music program (or track) is generally 

10 recorded in one part of a track data file. However, when 
the program is edited, the music program may be bro- 
ken into a plurality of parts. The relationship between 
one or more parts containing a single music program is 
managed witii part information PRTINF stored in the 

75 attribute header of each music program (see figure 6). 
The part size is represented witii part size PRTSIZE (4 
bytes) of the part information PRTINF. The first two 
bytes of the part size PRTSIZE represents the number 
of total clusters in the current part. The next two bytes 

20 represent ttie positions of the start sound unit (SU) and 
the end sound unit (SU) of tiie first and last clusters, 
respectively By this marking of parts, the movement of 
music data which occurs during editing can be tracked. 
[0048] SU is the minimum unit of a part com- 

25 pressed according to the ATRAC3 format. One SU is 
comprised of 1024 samples at 44.1 kHz (1024 x 16 bHs 
x 2 channels) and can be compressed by a factor of 1 0. 
This corresponds to around 23 msec of audio. Normally, 
a single part contains several thousand SU. Thus, a 

30 cluster composed of 42 SU, stores about a second of 
audio. 

[0049] Theoretically, the maximum number of parts 
comprising one track is 645. However, the actual 
number of parts usable in any given track is limited by 

35 the header, the program name, the additional data, and 
the size of the additional information. 
[0050] Figure 10 is a diagram showing tiie data 
an^ngemem of an ATRAC3 data file ASDnnnn where 1 
SU is N bytes (for example, N = 384 bytes). Figure 10 

40 also shows an attribute header (1 block) of a data file 
and a music data file (1 block)along with the first byte 
(0x0000 to 0x7FFF) of each slot of the two blocks (16 x 
2 = 32 kbytes). As shown In Figure 1 1 , the first 32 bytes 
of the attribute header are used as a header; 256 bytes 

45 are used as a music program area NM1 (256 bytes); 
and 512 bytes are used as a music program title area 
NM2 (512 bytes). The header of the ATRAC3 data file 
contains the following areas: 

so = BLKID-HDO (4 bytes) 

Meaning: BLOCKID FIELD ID 

Function: Identifies the top of an ATRA3 data 

file. 

55 Value: Fixed value = "HD = 0" (For example, 

0x48442 D30) 

= MCode (2 bytes) 
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Meaning: MAKER CODE 

Function: Identifies the maker and model of the 
recorderyt^layer 

Value: High-order 10 bits (maker code); low- 
order 6 bits (machine code) s 

: BLOCK SERIAL (4 bytes) 

Meaning: Track serial number 

Function: Starts from 0 and increments by 1. io 

Even if a music program is edited, this value 

does not vary. 

Value: 0 to OxFFFFFFFR 

N1C+L(2bytes) is 

Meaning: Represents the attribute of data 
(NM1) of a track (music program title). 
Function: Represent the character code and 
language code of NM1 as one byte code. 20 
Value: Same as SN1C+L 



Function: Used as a pointer that represents the 
top of a representative portion of a music pro- 
gram. The value of INX is designated with a 
value of which the number of SU is divided by 4 
as the current position of the program. This 
value of INX Is equivalent to 4 times larger than 
the number of SU (around 93 msec). 
Value: 0 to OxFFFF (max, around 6084 sec) 

= XT (2 bytes) (Option) 

Meaning: Reproduction duration of INDEX 
Function: Designates the reproduction duration 
designated by INX-nnn with a value of which 
the number of SU is divided by 4. The value of 
INDEX is equivalent to four times larger than 
the normal SU (around 93 msec). 
Value: 0x0000 (no setting); 0x01 to OxFFFE (up 
to 6084 see); OxFFFF (up to end of music pro- 
gram) 



N2C+L (2 bytes) 

Meaning: Represents the attribute of data 2s 
(NM2) of a track (music program title). 
Function: Represent the character code and 
language code of NM1 as one byte code. 
Value: Same as SNIC+L 

30 

INFSIZE (2 bytes) 

MocUiing: Total size of additional information of 
current track. 

Function: Represents the data size as a multi- 3S 
pie of 16 bytes. When data is not recorded, this 
area should be all 0. 
Value: 0x0000 to 0x3C6 (966) 



Next, the music program title areas NM1 and 
NM2 are described. 

Means: Character string of music program title 
Function: Represents a music program title as 
one byte code (up to 256 characters) (variable 
length). The title area should be completed with 
an end code (0x00). The size should be calcu- 
lated from the end code. When data is not 
recorded, null (0x00) should be recorded from 
the beginning (0x0020) of the area for at least 
one byte. 

Value: Various character codes 
=NM2 



T-PRT(2bytes) 40 

Meaning: Number of total bytes 
Function: Represents the number of parts that 
composes the current track. Normally, the 
value of T-PRT Is 1 . 45 
Value: 1 to 285 (645 dec). 

T-SU (4 bytes) 

Meaning : Number of total SU. so 
Function: Represents the total number of SU in 
one track that is equivalent to the program per- 
formance duration. 
Value: 0x01 to 0x001 FFFFF 

55 

INX (2 bytes) (Option) 
Meaning: Relative position of INDEX 



Means: Character string of music program title 
Function: Represents a music program title as 
two byte code (up to 512 characters) (variable 
length). The title area should be completed with 
an end code (0x00). The size should be calcu- 
lated from the end code. When data is not 
recorded, null (0x1 00) should be recorded from 
the beginning (0x0120) of the area for at least 
two bytes. 

Value: Various character codes 

[0051 ] Data of 80 bytes starting from the fixed posi- 
tion (0x320) of the attribute header is referred to as track 
information area TRKINF This area is mainly used to 
totally manage the security information and copy control 
information off the particular track. Figure 12 shows a 
part of TRKINR The TRKINF area contains the following 
areas. 
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= CONTENTS KEY (8 bytes) 

Meaning: Value for each music program. The 
value of CONTENTS KEY is protected in the 
security blocl^ of the memory card and then s 
stored. 

Function: Used as a key for reproducing a 
music program. It is used to calculate the value 
of MAC. 

Value: 0 to OxFFFFFFFFFFFFFFFF io 

=MAG (8 bytes) 

Meaning: Forged copyright information checl< 
value 75 
Function: Represents the value generated with 
a plurality of values of TRKINF including con- 
tents cumulation numbers and a secret 
sequence number. The secret sequence 
number is a sequence number recorded in the 20 
secret area of the memory card. A non-copy- 
right protection type recorder cannot read data 
from the secret area of the memory card. On 
the other hand, a copyright protection type 
recorder and a computer that operates with a ss 
program that can read data from a memory 
card can access the secret area. 



A(1 byte) 



30 



Meaning: Attribute of part. 

Function: Represents the information of such 

as compression mode of a part. 

Value: see discussion hereinafter (see Figures. 

12 and 13). as 



[0052] Ne}ct. the value of area A is described. In the 
following description, monaural mode (N = 0 or 1) is 
defined as a special joint mode of which bit 7 1 , sub 
signal =0, and main signal = (L+R). A player without 40 
copyright protection capability may ignore information 
bits 2 and 1 . 

[0053] Bit 0 of the area A states whether emphasis 
is on or off. Bit 1 indicates slop reproduction or normal 
reproduction. Bit 2 designates the data type such as 45 
audio data, FAX data, or the like. Bit 3 is undefined. 
Mode information for ATRAC3 is represented by the 
combination of bits 4, 5, and 6, as shown in Figure 13. 
In other words, N indicates mode and is represented by 
3 bits. In Figure 13, for the five types of modes listed so 
(monaural (N =0 or 1), LP (N = 2), SP (N = 4), EX (N = 
5), and HQ (N = 7)), record duration (64 MB memory 
card only), data transmission rate, and the number of 
SU per block are provided. The number of bytes in each 
SU depends on the defined mode. In the monaural ss 
mode 1 SU Is 136 bytes. In the LP mode 1 SU is 192 
bytes. In the SP mode 1 SU is 304 bytes. In the EX 
mode 1 SU is 384 bytes. In the HQ mode 1 SU is 512 



bytes. Bit 7 of area A represents ATRAC3 type modes 
(0: Dual. 1 : Joint). 

[0054] As an example , a 64 MB memory card used 
in the SP mode is described. A 64 MB memory card has 
3968 blocks. In the SP mode, since 1 SU Is 304 bytes, a 
block is comprised of 53 SUs. Hence, 1 SU is equivalent 
to (1 024/441 00) seconds. Thus, a 64 MB memory card 
stores (1024/44100) x 53 x (3968 - 10) 4863 seconds 
= 81 minutes. The transmission rate Is (44100/1024) x 
304x8 = 104737 bps. 

[0055] Referring back to Figure 12, the remainder 
of the areas of TRKINF will be described. 

=LT (one byte) 

Meaning: Reproduction restriction flag (bits 7 
and 6) and security partition (bits 5 to 0). 
Function: Represents a restriction of the cur- 
rent track. 
Value: 

bit 7: 0 = no restriction, 1 = restriction 
bit 6: 0 = not expired, 1 = expired 
bits 5 to 0: security partition (reproduction 
prohibited other than 0) 

=FNo (2 bytes) 

Meaning: File number. 

Function: Represents the initially recorded 
track number that designates the position of 
the MAC calculation value recorded in the 
secret area of the memory card. 
Value: 1 to 0x1 90 (400) 

= MG(D) SERIAL-nnn (1 6 bytes) 

Meaning: Represents the serial number of the 
security block (security IC 20) of tiie 
recorder/player. 

Function: Unique value for each 
recorder/player 

Value: 0 to 

OxFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 

= CONNUM (4 bytes) 

Meaning: Contents cumulation number 
Function: Represents a unique value cumu- 
lated for each music program. The value is 
managed by the security block of ttie 
recorder/player. The upper limit of the value is 
232 that is 4,200,000,000. Used to identify a 
recorded program. 
Value: 0 to OxFFFFFFFF 

= YMDhms-S (4 bytes) (Option) 
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Meaning: Reproduction start date and time of 
track with reproduction restriction 

Function: Represents the date and time at 
wliich data reproduction is permitted with EMD. s 

Value: Same as the notation of date and time of 
other areas 

YMDhms-E (4 bytes) (Option) io 

Meaning: Reproduction end date and time of 
track with reproduction restriction 
Function: Represents the date and time at 
which data reproduction is expired with EMD. 75 
Value: Same as the notation of date and time of 
other areas 

MT (1 byte) (Option) 

20 

Meaning: Maximum value of number of permit- 
ted reproduction times 

Function: Represents the maximum number of 
reproduction times designated by EMD. 
Value: 1 to OxFR When not used, the value of 25 
the area MT is 00. 

CT (1 byte) (Option) 

Meaning: Number of reproduction times 30 
Function: Represents the number of reproduc- 
tion times in the number of permitted reproduc- 
tion times. Whenever data is reproduced, the 
value of the area CT is decremented. 
Value: 0x00 to OxFR When not used, the value 3S 
of the area CT is 0x00. When bit 7 of the area 
LT is 1 and the value of the area CT is 00, data 
is prohibited from being reproduced. 

CC (1 byte) 40 

Meaning: COPY CONTROL 
Function: Controls the copy operation. 
Value: (see figure 14) bits 6 and 7 represent 
copy control information, bits 4 and 5 represent 45 
copy control Information of a high speed digital 
copy operation, bits 2 and 3 represent a secu- 
rity block authentication level, bits 0 and 1 are 
undefined. 

Example of CC: so 

(bits 7 and 6) 

1 1 : Unlimited copy operation permitted 
01: copy prohibited 

00: one time copy operation permitted ss 
(bits 3 and 2) 

00: analog/digital input recording 



MG authentication level is 0. When digital 
record operation using data from a CD is 
performed, (bits 7 and 6): 00 and (bits 3 
and 2): 00. 

= CN (1 byte) (Option) 

Meaning: Number of permitted copy times in 
high speed serial copy management system 
Function: Extends the copy permission with the 
number of copy times, not limited to one time 
copy permission and copy free permission. 
Valid only in first copy generation. The value of 
the area CN is decremented whenever the 
copy operation is performed. 
Value: 

00: Copy prohibited 

01 to OxFE: Number of times 

OxFF: Unlimited copy times 

[0056] Referring once again to Figure 10, the track 
information area TRKINF is followed by a 24-byte part 
management information area (PRTINF) starting at 
0x0370. When a track is composed of a plurality of 
parts, the addresses of tiie individual parts are succes- 
sively arranged in PRTINF. Figure 15 shows a portion of 
the PRTINF area. Next, the PRTINF area is described in 
order of arrangement. 

= PRTSIZE (4 bytes) 

Meaning: Part size 

Function: Represents the size of a part. Clus- 
ter: 2 bytes (highest position), start SU: 1 byte 
(upper), end SU: 1 byte (lowest position). 
Value: 

cluster: 1 to 0x1 F40 (8000) 

start SU: Oto 0xA0(160) 

end SU: 0 to OxAO (16) (Note ttiat SU 

starts from 0.) 

= PRTKEY (8 bytes) 

Meaning: Part encrypting value 

Function: Encrypts a part. Initial value =0. Note 

that edit rules should be applied. 

Value: 0 to OxFFFFFFFFFFFFFFFF 

= CONNUMO (4 bytes) 

Meaning: Initially generated contents cumula- 
tion number key 

Function: Uniquely designates an ID of con- 
tents. 

Value: Same value as the value of the contents 
cumulation number initial value key 
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[0057] As is next shown In Figure 10, the attribute 
header of an ATRAC3 data file contains an additional 
information INF area. The additional information is the 
same as the additional information INF-S area (see Fig- 
ures 7 and 8) of the reproduction management file 5 
except that the start position is not fixed. The last byte 
position (a multiple of four bytes) at the end of one or a 
plurality of parts is followed by the additional information 
INF area. 

10 

= INF 

Meaning: Additional information with respect to 
track 

Function: Represents variable length additional 75 
information with a header. A plurality of differ- 
ent types of additional information may be 
an-anged. Each of additional information areas 
has an ID and a data size. Each additional 
information area is composed of at least 16 20 
bytes and a multiple of 4 bytes. 
Value: Same as additional information INF-S of 
reproduction management file 

[0058] The above-described attribute header is fol- 25 
lowed by a plurality of data blocks. To each data block a 
header is added. Next, each block of the added header 

as shown In Figure 1 6 is described. 

= BLKID-A3D (4 bytes) 30 

Meaning: BLOCKID FILE ID 
Function: Identifies the top of ATRAC3 data. 
Value: Fixed value = "A3D" (for example, 
0x41334420) 35 

= MCode (2 bytes) 

Meaning: MAKER CODE 

Function: Identifies the maker and model of the 4o 
recorder/player 

Value: High-order 10 bits (maker code); low- 
order 6 bits (model code) 

= CONNUMO(4bytes) 45 

Meaning: Cumulated number of initially created 
contents 

Functton: Designates a unique ID for contents. 
Even if the contents are edited, the value of the so 
area CONNUMO is not changed. 
Value: Same as the contents cumulation 
number initial key 

= BLOCK SERIAL (4 bytes) ss 

Meaning: Serial number assigned to each track 
Function: Starts from 0 and increments by 1. 



Even if the contents are edited, the value of the 
area BLOCK SERIAL is not changed. 
Value: 0 to OxFFFFFFFF 

= BLOCK-SEED (8 bytes) 

Meaning: Key for encrypting one block 
Function: The beginning of the block is a ran- 
dom number generated by the security block of 
the recorder/player. The random number is fol- 
lowed by a value incremented by 1 . When tiie 
value of the area BLOCK-SEED is lost, since 
sound is not generated for around one second 
equivalent to one block, the same data is writ- 
ten to the header and the end of the block. 
Even if the contents are edited, the value of the 
area BLOCK-SEED is not changed. 
Value: Initially 8-bit random number 

= INITIALIZATION VECTOR (8 bytes) 

Meaning: Value necessary for encrypt- 
ing/decrypting ATRAC3 data 
Function: Represents an initial value neces- 
sary for encrypting and decrypting ATRAC3 
data for each block. A block starts from 0. The 
next block starts from the last encrypted 8-bit 
value at the last SU. When a block is divided, 
the last eight bytes just before the start SU is 
used. Even if the contents are edited, the value 
of the area INITIALIZATION VECTOR is not 
changed. 

Value: 0 to OxFFFFFFFFFFFFFFFF 
= SU-nnn 

Meaning: Data of sound unit 
Function: Represents data compressed from 
1024 samples. The number of bytes of output 
data depends on the compression mode. Even 
if the contents are edited, the value of the area 
SU-nnn is not changed. For example, in the SP 
mode, N = 384 bytes. 
Value: Data value of ATRAC3 

[0059] In Figure 10. since N = 384, 42 SUs are writ- 
ten to one block. The first two slots (4 bytes) of the block 
are used as a header. In the last slot (two bytes). 
BLKID-A3D. MCode, CONNUMO, and BLOCK SERIAL 
are redundantly written. Thus, M bytes of the remaining 
area of one block is (16,384 - 384 x 42 - 16 x 3 = 208) 
bytes. As described above, the eight-byte area BLOCK 
SEED is also redundantiy recorded. 
[0060] Further, tiie sound units SU(0)~(101) are 
each comprised of an 8-byte cryptogram Cj created by 
encryption in units of 64-bit (8-byte) cipher blocks in the 
CBC (cipher block chaining) mode in the encrypt- 
ing/decrypting unit 64 shown in Figure 2. In the present 
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embodiment, the number of bytes (for example 160 
bytes) of the sound unit SU is made a whole multiple of 
the number of bytes (for example 8 bytes) of a cipher 
block, that is, the unit of enayption. Namely, one sound 
unit SU is comprised of, for example. 20 cryptograms Cj. 5 
Each cryptogram Cj is located within a sound unit SU, 
and a cryptogram Ci never straddles a plurality of sound 
units SUs. 

[0061] The audio data stored in flash memory 34 is 
compressed as mentioned later. The unit of compres- 10 
sion is the sound unit SU. Accordingly, when audio data 
is read from the portable storage device 3 to the porta- 
ble player 4, the minimum readable unit is a sound unit 
SU. Because of this, there are no breaks between 
encryption blocks and the processing load Id access the is 
data is thereby reduced when accessing encrypted 
audio data stored in the flash memory 34. Note that the 
number of sound units SU contained in each cluster 
may be any number within a range from 1 to 102. Fur- 
ther, the compression method for the audio data may be 20 
ATRAC3 or another CODEC method. 
[0062] The block seed data BS is created by gener- 
ating random numbers for every cluster and. as men- 
tioned later, is used when creating block key data BK for 
every block in portable player 4. The block seed data BS 2s 
is stored in two positions in each block as a counter- 
measure against errors. Further, the sound units in 
each of the clusters is stored at consecutive addresses 
in flash memory 34 by order of encryption. Thus, the 
encryption blocks are stored consecutively in flash 30 
memory 34 in the order of encryption. 

Flash Memory Management Module 35 

[0063] The flash memory management module 35 35 
performs control for the writing of data to the flash mem- 
ory 34 and for the reading of data from the flash mem- 
ory 34, etc... 

Portable Player 4 40 

[0064] As shown once again in Figure 2, portable 
player 4 is comprised of a main control module 41, a 
communication interface 42, a control module 43, an 
edit module 44, a compression/expansion nrxxiule 45, a 45 
speaker 46. a D/A converter 47. and an A/C converter 
48. 

Main Control Module 41 

so 

[0065] Main control module 41 centrally controls 
processing by the portable player 4. 

Control Module 43 

55 

[0066] Control module 43 includes a random 
number generation unit 60, a storage unit 61 , a key cre- 
ation/key processing unit 62, a mutual identification unit 



63, an encrypting/ decrypting unit 64, and a control unit 
65. 

[0067] Control module 43 may be formed as a sin- 
gle chip integrated circuit with a multilayer structure sim- 
ilar to the control module 33 used exclusively for 
encryption. The internal memory cells are sandwiched 
between dummy layers (such as aluminum layers). Fur- 
ther, control module 43 has a narrow range of operating 
voltage or operating frequency and is tamper resistant 
to prevent data form being illicitly read from the outside. 
[0068] Random number generation unit 60 gener- 
ates a 64bit (8-byte) random number upon receipt of a 
random number generation instruction. 
[0069] Storage unit 61 stores various data required 
for the Identification. As shown in Rgure 1 7, storage unit 
61 stores the master key data MKq to MK31 and the 
device identification data 10^- 
[0070] Equation (1) below shows the relationship 
between the master key data MKq to MK31, identifica- 
tion keys IKq to IK31. and the device identification data 
IDn,. In the following equation, f(a b) is a function for 
deriving a value from the arguments a and b. 

IKj=f(MKj,IDJ (1) 

where, j is an integer satisfying 0 < j < 31 . 
[0071] The storage addresses of the identification 
keys IKq to IK31 in the storage unit 61 are expressed by 
5 bits. They are assigned corresponding storage 
addresses with those for the master key data MKq to 
MK31 in the storage unit 51. 

[0072] Key creation/key processing unit 62 creates 
the key data by performing various operations (e.g., the 
MAC operation defined in ISO/IEC9797). At this time. 
DES prescribed in FIPS PUB 46-2 is used as the "block 
cipher algorithm". 

[0073] Mutual identification unit 63 performs a 
mutual identification process with the portatjie storage 
device 3 prior to the transfer of audio data from compu- 
ter 2 to portable storage device 3. Mutual identification 
unit 63 also performs a mutual identification process 
with portable storage device 3 before the receipt of 
audio data from portable storage device 3. Further, 
mutual identification unit 63 performs the MAC opera- 
tion and makes use of the data stored in the storage unit 
61, during a mutual identification process. Mutual iden- 
tification unit 63 performs the mutual identification proc- 
ess with computer 2 or the computer on network 5 
before audio data is input or output to those devices. 
[0074] Encrypting/decrypting unit 64 performs 
block encryption by selectively using the ECB mode or 
CBC mode described in FIPS PUB 81. Encrypt- 
ing/decrypting unit 64 uses the 56-bit key k in the CBC 
mode to encrypt audio data (plain text) input from com- 
puter 2 or CD player 7 in units of cipher blocks consist- 
ing of 64 bits based on equation (2) below, thereby 
creating the encrypted audio data (cryptogram). 
[0075] In the CBC mode, the preceding Is used to 
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encrypt the following group of data. Thus, a different 
cryptogram is output even when identical data is Input. 
This makes deciphering difficult. 

Ci=EK(PiXORC,,) (2) 

where, 

i: integer of 1 or more 
Pj: plain text (64 bits) 
Cj: cryptogram (64 bits) 
XOR: exclusive OR. and 

E^: encryption by DES system using 56-brt key data 
k 

[0076] The operation of equation (2) will now be 
explained making reference to Figure 18. "IV" is the 
block encryption initial value (64 bits) and Is stored 
immediately preceding the sound unit SU(0) in the dus- 
ter CL In the flash memory 34 of portable storage device 
3. 

[0077] ATRAC is the coding and compressing 
method used in MiniDisks®, and In which a 288 kbit/s 
44.1 kHz sample stereo signal is encoded using band 
division and MDCT (modified discrete cosine transform) 
First, data is divided into three bands of 1/4. 1/4, and 
1/2, by a band division filter, signals of bands are down- 
sampled and converted Into the frequency domain by 
MDCT and the coefficient of the MDCT is scalarly quan- 
tized by adaptive bit distribution. 
[0078] Encrypting/decrypting unit 64 selectively 
performs decryption using the ECB mode and CBC 
nxxJe 15 from amongst the FIPS81 modes. Encrypt- 
ing/decrypting unit 64 creates plain text by decrypting a 
cryptogram in units of cypher blocks using the 56-bit key 
k in accordance with equation (3), shown below. 

Pi=C,^XORD,(Cj) (3) 

where, 

i: Integer of 1 or more 
Pj: plain text (64 bits) 
Cj: cryptogram (64 bits) 
XOR: exclusive OR, and 

D^: decryption of DES system using 56-bit key data 

[0079] The operation of equation (3) will now be 
explained making reference to Figure 19. Note that. In 
Figure 19, "IV is the block encryption initial value (64 
blts)and is stored immediately preceding the sound unit 
SU(0) In the cluster CL In the flash memory 34 of the 
portable storage device 3. 

[0080] Control unit 65 centrally controls the 
processing of random number generation unit 60, stor- 
age unit 61, key creation/processing unit 62, mutual 
Identification unit 63, and the encrypting/decrypting unit 
64. 



Editing Module 44 

[0081] Editing module 44 edits the track data files 
1 01 0 to 101 3 (see figure 4) stored in flash memory 34 of 

5 potable storage device 3 to create a new track data file 
based on an instruction from the user. This editing can 
Include divisional editing where one track data file is 
divided into two track data files, and coupled editing 
where two track data files are merged into one track 

10 data file. As a result of such editing, the reproduction 
management file 100 and the track data files IOIq to 
101 3 are rewritten as necessary. 

Compression/Expansion Module 45 

15 

[0082] As part of the process to reproduce 
encrypted audio data, the compression/expansion mod- 
ule 45 expands compressed ATRAC3 audio data and 
outputs it to D/A converter 47. Further, module 45 oom- 
20 presses audio data using the ATRAC3 format when 
storing audio data input from CD player 7 or computer 2 
in portable storage device 3. 

D/A Converter 47 

25 

[0083] The D/A converter 47 converts digital audio 
data input from compression/expansion module 45 to 
analog audio data which is output to the speaker 46. 

30 Speaker 46 

[0084] The speaker 46 outputs sound according to 
the audio data input from the D/A converter 47. 

35 A/D Converter 48 

[0085] The A/D converter 48 converts analog audio 
data input from CD player 7 into digital data for output to 
compression/expansion module 45. 

40 

Write Operation to Portable Storage Device 3 

[0086] Figure 20 is a flow chart explaining an oper- 
ation for writing data from portable player 4 to portable 

45 Storage device 3. 

[0087] Step SI : A write request signal is sent from 
portable player 4 to portable storage device 3. 
[0088] Step S2: The Identification key data IKj used 
for mutual identification between portable storage 

so device 3 and portafc)le player 4 Is selected. The process- 
ing in this step Is explained in greater detail below. 
[0089] Step S3: A mutual identification process is 
performed between portable storage device 3 and port- 
able player 4. The processing in this step Is explained in 

55 greater detail below. 

[0090] Step S4: When portable storage device 3 
and portable player 4 each recognize that the other 
party is legitimate in accordance with the mutual identi- 
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f ication process of step S3, control passes to step S5. 
Otherwise, processing Is terminated. 

[0091] Step S5: A session key data Sek is created 
in both portable storage device 3 and portable player 4. 
The processing in this step will be explained in greater s 
detail below. 

[0092] Step S6: Encrypted audio data is output and 
written from portable player 4 to portable storage device 
3 via communication interlaces 32 and 42. The process- 
ing in this step will be explained In greater detail below. io 
[0093] In this manner, a mutual identification proc- 
ess is carried out between portable storage device 3 
and portable player 4. and the encrypted audio data is 
written from portable player 4 to portable storage device 
3 only when each recognizes the other party as legiti- is 
mate. By this method, illicit copying of audio data is eas- 
ily avoided. 

Selection of Identification Kev Data IKj (step S2 of Fig- 
ure 20) 20 

[0094] Figure 21 explains the selection of the iden- 
tification key data IKj as originally noted In step 82 of 
Figure 20. A 64-bit random number Rj is created by ran- 
dom number generation unit 60 of portable player 4 25 
shown in Rgure 2. The random number Rj is output 
from portable player 4 to portable storage device 3. 
IVIutual identification unit 53 of portable storage device 3 
uses the lower significant 5 bits of the 64-blt random 
number Rj to specify an Identification key data IKj 3o 
(where j Is an integer satisfying 0 < j < 31) from the 
prestored identification key data IKq to XK^^ stored in 
storage unit 51. The device identification data is 
similarly read from storage unit 51 of portable storage 
device 3 and output to portable player 4. The mutual 35 
identification unit 63 of portable player 4 uses the lower 
significant 5 bits of the random number Rj to specify a 
master key data Ml^ from the prestored master key data 
MKotoMKgi. 

[0095] Key creation/key processing unit 62 uses the 40 
specified master key data MKj and the device identifica- 
tion data IDm to create the identification key data IKj 
based on equation (4), shown below. Note, f(ap b) is any 
function for deriving a value from, tor example, the argu- 
ments a and b. 45 

IKj = f(MKjJDJ (4) 

[0096] Once portable storage device 3 and portable 
player 4 have the identification key data IKq to IK31 and so 
the master key data MKq to MK31 having the relation- 
ship shown In equation (4). the same identification key 
data IKj is selected by the processing shown in Rgure 
21. 

[0097] The selected identification key data IKj is ss 
used as the secret key in the mutual Identification proc- 
ess, as will be described below. Whenever the process- 
ing shown in Figure 21 Is carried out, the identification 



key data is selected at random according to the random 
number Rj from among the 32 identification key data IKj 
This reduces the probability of successfully faking illicit 
identification to 1/32 of that of the case where only one 
Identification key data is used, thus providing a high 
probability of avoiding illicit identification. 

[0098] In the above embodiment, the identification 
key data is selected using a random number. But it is 
also possible to determine the identification key data 
based on a key designation signal input from outside of 
portable storage device 3 and portable player 4. 

Mutual Identification Between Portable Storage Device 
3 and Portable Plaver 4 ( step Sa of Rgure 20) 

[0099] Figure 22 Is a view for explaining the mutual 
Identification process performed between portable stor- 
age device 3 and portable player 4. Prior to starting the 
mutual identification process, the selection of the identi- 
fication key data IKj shown in Figure 21 has been com- 
pleted and mutual Identification unit 63 of portable 
player 4 has the selected identification key data IKj and 
the device identification data ID^. Further, mutual iden- 
tification unit 63 of portable storage device 3 has the 
selected identification key data IKj and tiie device iden- 
tification data IDni of portable storage device 3. The 
mutual Identification proceeds as follows. 
[0100] Step S10: Random number generation unit 
50 of portable storage device 3 creates a 64-blt random 
number R^^^ and outputs it to portable player 4. 
[0101] Step 811: Random number generation unit 
60 of portable player 4 creates tiie 64-bit random num- 
bers Rd and S^. 

[0102] Step S12: Mutual identification unit 63 of 
portable player 4 uses the Identification key data IKj 
obtained at step S2 shown in Figure 20 and "Rd || R^s 
II IDm" to carry out a MAC operation based on equation 
(5) as shown below, to find MAC^. Here, A||B Indicates 
the coupling of A and B (coupling of m-bit B to end of n- 
blt A to make (n+m) bits). 

MACA=MAC(IKj,Rdl|R^||IDJ (5) 

[01031 Step SI 3: Portable player 4 outputs 
"RdllSdl|MACAl|j" to portable storage device 3. 
[0104] Step SI 4: Mutual identification unit 53 of 
portable storage device 3 uses identification key data IKj 
obtained at step S2 shown in Figure 20 and the 
"RdllRmsll 'Dm" to canry out a MAC operation tased on 
equation (6). as shown below, to find MACg. 

MAC B=MAC(IKj,R J|R ^3||ID J (6) 

[0105] Step SI 5: Mutual identification unit 53 of 
portable storage device 3 conpares the MACb found at 
step SI 4 and the MAC^ input at step Si 3. If they coin- 
cide, the portable player 4 has an adequate Identifica- 
tion key data IKs, so portable storage device 3 identifies 
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it as a legitimate party. 

[0106] Step S16: Mutual identification 53 of porta- 
ble storage device 3 uses identification key data IKj 
obtained at step S2 shown In Figure 20 and "RmsllF^" to 
carry out a MAC operation based on equation (7) to find s 
MACc. 

MACc-MAC(IKj.R^IIRd) (7) 

[0107] Step SI 7: Random number generation unit w 
50 of portable storage device 3 creates the 64-bit ran- 
dom number Sms- 

[01 08] Step 81 8: "Smsl I MACc" is output from port- 
able storage device 3 to portable player 4. 
[0109] Step 819: Mutual Identification unit 63 of 75 
portable player 4 carries out the MAC operation based 
on equation (8) to find MACd- 

MACd=MAC(IKj.R^3l|Rd) (8) 

20 

[0110] Step 820: Mutual Identification unit 53 of 
portable player 4 compares MAC^ found at step 819 
and MACc input at step 818. If they coincide, portable 
storage device 3 has an adequate identification key 
data IKj, so portable player 4 identifies it as a legitimate 2S 
party. 

[01 1 1 ] In accordance with the above, mutual identi- 
fication between portable storage device 3 and portable 
player 4 is achieved. 

30 

Creation of Session Kev Data Sek (step 85 of Fioure 

m 

[0112] Figure 23 explains the creation of the ses- 
sion key data Sek. Prior to starting the creation of the 35 
session key data Sek, the selection of the identification 
key data IKj shown in Rgure 21 and the mutual identifi- 
cation process shown in Rgure 22 are complete. Both 
portal3le storage device 3 and portable player 4 have 
the selected identification key data IKj and the random 4o 
numbers 8^ and Sf^is- The creation of session key data 
Sek progresses as follows. 

[0113] Step 830: Mutual identification unit 63 of 
portat)le player 4 uses the selected Identification key 
data IKj and "Sd||Sms" to perform a MAC operation 45 
based on equation (9) to create the session key data 
Sek. 

Sek=MAC(IKj.SJ|S^3) (9) 

50 

[0114] Step 831: Mutual identification unit 53 of 
portable storage device 3 uses the selected identifica- 
tion key data IKj and "Sd ||Sms" to perform a MAC oper- 
ation based on equation (10) to create the session key 
data Sek. ss 

Sek=MAC(IKj.SJ|S^3) (10) 



[01 15] The session key data Sek created at porta- 
ble storage device 3 is the same as the session key data 
Sek created at portable player 4 if both parties are legit- 
imate. 

Writino of Audio Data into Portable Storaae Device 3 
(step S6 of Figure 20) 

10116] Figure 24 explains the write processing of 
audio data from portable player 4 into portable storage 
device 3. Prior to starting the write processing, the cre- 
ation processing of the session key data Sek shown in 
Rgure 23has been completed and portable storage 
device 3 and portable player 4 have the same session 
key data Sek. The writing of audio data into portable 
storage device 3 progresses as follows. 
[0117] Step S40: Portable player 4 requests ran- 
dom number generation unit 60 to generate a random 
number for each track and create a corresponding con- 
tent key data CK according to each of the random num- 
bers. 

[01 1 8] Step 841 : Portable player 4 encrypts content 
key data CK created at step 840 in encrypting/decrypt- 
ing unit 64 by using the session key data Sek. 
[01 19] Step S42: Portable player 4 outputs content 
key data CK encrypted at step 841 to portable storage 
device 3. 

[0120] Step 843: Portable storage device 3 

decrypts encrypted content key data CK input at step 

842 in encrypting/decrypting unit 54. 

[0121] Step 844: Portable storage device 3 

encrypts content key data CK decrypted at step S43 In 

the encrypting/decrypting unit 54 by using the storage 

use key data Skm read from storage unit 51 . 

[01 22] Step 845: Portable storage device 3 outputs 

the encrypted CKto the portable player 4. 

[01 23] Step 846: Portable player 4 sets the related 

encrypted content key data CK in the TRKINF in track 

data file lOln- 

[0124] Step 847: Random number generation unit 
60 generates a random number for each part of a track 
data file and creates part key data PK according to the 
random number. The created part key data PK is set in 
the management data PRTINF of track data file 101^. 
[01 25] Step 848: The XOR of part key data PK cre- 
ated at step 845 and content key data CK is obtained in 
key creation/processing unit 62 for each part of the track 
data file as shown below in equation (11). The result of 
the processing is the generation of a temporary key 
data TMK. The creation of temporary key data TMK is 
not limited to using an XOR function. It is possible to use 
other functional operators, such as a simple AND oper- 
ator. 

TMK=PKXORCK (11) 

[0126] Step 849: Random number generation unit 
60 generates a rarxlom number for each block and cre- 
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ates block seed data BS according to the random 
number. Further, portable player 4 sets the created 
block seed data BS Into its proper position in each cor- 
responding block. 

[0127] Step S50: Key creation/key processing unit s 
62 uses the temporary key data TMK created at step 
S46 and the block seed data BS created at step S47 in 
equation (12) to perfbnri a MAC operation and create 
block key data BK Ibr each block. 

10 

BK = MAC (TMK. BS) (12) 

[0128] It Is possible to perform processing other 
than a MAC operation by using the secret key on the 
input of a SHA-1 (secure Hash algorithm), RIPEMD- is 
160, or other one-way Hash function to create block key 
data BK. Here, the one-way function f defines a function 
from which it is easy to calculate y = f (x) from x, but con- 
versely difficult to find x from y. A one-way Hash function 
Is described in detail in the "Handbook of Applied Cryp- 20 
tography, CRC Press". 

[0129] Step S51 : Portable player 4 compresses the 
audio data input from computer 2 or portable player 4 in 
accordance with the ATRAC3 format in compres- 
sion/expansion module 45. Then, encrypting/decrypting 25 
unit 64 encrypts the compressed audio data in the CBC 
mode by using the block key data BK created at step 
S50. 

[0130] Step S52: Portable player 4 adds headers to 
the audio data encrypted at step S51 and outputs them 30 
via the communication interfaces 32 and 42 to portable 
storage device 3. 

[0131] Step S53: Portable storage device 3 writes 
the encrypted audio data and header into flash memory 

34. 35 

[0132] At this point writing of the audio data from 
the portable player 4 to the portable player 4 is com- 
plete. Although the above description only discusses 
writing track data files IOI0 to IOI3, the portable player 
4 also writes the reproduction management file 100 in 40 
this manner. 

Reading from Portable S torage Device 3 

[0133] Figure 25 is a flow chart explaining a read 45 
operation for reading data from portable storage device 
3 to portable player 4. 

[0134] Step S61 : A read request signal specifying a 
desired track data (tune) Is sent from portable player 4 
to portable storage device 3. so 
[0135] Step S2: The identification key data IKj used 
when performing the mutual identification between the 
portable storage device 3 and the portable player 4 is 
selected in a manner as described above. 
[0136] Step S3: Mutual identification processing is ss 
performed between portable storage device 3 and port- 
able player 4 in a manner as described above. 
[0137] Step S4: Where both portable storage 



device 3 and portable player 4 identify each other as 
legitimate, the processing proceeds. Otherwise, 
processing is terminated. 

[0138] Step S5: Session key data Sek is created at 
portable storage device 3 and portable player 4 in a 
manner as described above. 

[01 39] Step S63: The encrypted audio data is read 
via communication interfaces 32 and 42 from portable 
storage device 3 to portable player 4. This processing 
will be explained in greater detail below. 
[0140] Mutual identification is carried out between 
portable storage device 3 and portable player 4. Only 
when the two parties identify each other as legitimate 
can the encrypted content key data be decrypted using 
the proper session key data Sek. Therefore, illicit utiliza- 
tion of the audio data is easily avoided. 

Reading of Audio Data from Portable Storaoe Device 3 
(step S63 of Figure 25^ 

[0141 J Figure 26 explains the reading of audio data 
from portable storage device 3 to portable player 4. This 
reading step requires the data to be written by the 
above described method. The writing of the track data 
files IOIq to IOI3 is critical to set the content key data 
CK in the TRKINF, the part key data PK in the PRTINF. 
and the block seed data BS in each cluster GL. Because 
the processing of step S5 is complete, portable storage 
device 3 and portable player 4 have the same session 
key data. The reading of audio data from portable stor- 
age device 3 proceeds as follows. 
[0142] Step S71: Portable storage device 3 speci- 
fies the track data file corresponding to the read request 
signal and outputs the audio data in sound units SUs 
from the cluster comprising the specified track data. 
Portable storage device 3 also reads out the con-e- 
sponding attribute header of the audio data and outputs 
It to portable player 4. 

[01 43] Step S72 : Portable player 4 picks-up the CK 
from the TRKINF in the irput attribute header and out- 
puts it to portable storage device 3. 
[0144] Step S73: Encrypting/decrypting unit 54 of 
portable storage device 3 decrypts the content key data 
CK input at step S72 using the storage key data Skm 
stored In storage unit 51. 

[0145] Step S74: Encrypting/decrypting unit 54 of 
portable storage device 3 encrypts the content key data 
CK decrypted at step S73 using the session key data 
Sek obtained at step S5 shown in Figure 25. 
[0146] Step S75: Portable storage device 3 outputs 
the content key data CK encrypted at step S74 to port- 
able player 4. 

[0147] Step S76: Encrypting/decrypting unit 64 of 
portable player 4 decrypts the content key data CK Input 
from the portable storage device 3 at step S73 using the 
session key data Sek. 

[0148] Step S77: Key creation/processing unit 62 of 
portable player 4 obtains the XOR of the content key 
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data CK decrypted at step S76 and the part key data PK 
from the PRTINF In the attribute header being input at 
step 871 and defines the result of the processing as the 
temporary key data TMK in accordance with equation 
(13). 5 

TIVlK=PKXORCK (13) 

[0149] Step S78: Key creation/key processing unit 
62 of portable player 4 uses the temporary key data io 
TMK created at step 877 and the block seed data B8 in 
the track data file Inputted at step 871 to perform the 
MAC operation shown in the following equation (1 4) and 
defines the result of the processing as the block key 
data BK. The block key data BK is found for every clus- 75 
ter (block) as follows. 

BK = MAC (TMK. BS) (14) 

[0150] Step 879: Portable player 4 decrypts the 20 
audio data input at step S71 in encrypting/decrypting 
unit 84 by using the block key data BK created at step 
878. 

[0151] At this point, the audio data is decrypted for 
every cluster (block) using the individually found block 25 
key data BK. Further, decryption is carried out in the 
same 8-byte blocks as used for encryption. 
[0152] Step 880: Portable player 4 expands the 
audio data decrypted at step 879 by the ATRAC3 sys- 
tem In compression/expansion module 45 and converts 30 
the expanded audio data to a digital format at D/A con- 
vener 47 for output to speaker 46. 
[0153] The audio data decrypted at step S78 is 
expanded in sound units SUs. 

35 

Divisional Editina of Track Data File 

[0154] As previously mentioned, editing module 44 
of portable player 4 is adapted to perform the divisional 
editing of dividing one track data file to create two track 40 
data files and the coupled editing of coupling two track 
data files to create one track data file. 
[0155] First, an explanation of divisional editing is 
provided. Figure 27 explains the divisional editing of a 
track data file by editing module 44 of portable player 4. 45 
As an example, editing module 44 divides a track data 
file (1) shown in Figure 27(A) into a new track data file 
( 1 ) shown in Figure 27(B) and a track data file (2) shown 
in Figure 27(C). The minimum divisible unit is the sound 
unit SU. In this example, the sound units SU(3) and so 
8U(4) of cluster CL(2) are divided as shown in Figure 
27(B). 

[0156] After division, cluster CL(2) of track data file 
(1) is as shown in Figure 28. and cluster CL(0) of the 
newly created track data file (2) is as shown in Figure ss 
29. Sound unit SU(4) of cluster (2) of track data file (1) 
before the division, becomes sound unit 8U(0) of cluster 
CL(0) in track data file (2). Similarly, sound unit 8U (5) of 



the cluster (2) of track data file (1) before the division, 
becomes sound unit 8U(1) of cluster CL(0) of track data 
file (2). 

[P157] Further, the block encryption Initial value IV 
of cluster CL (0) of track data file (2) is set equal to the 
last 8 bytes of sound unit 8U (3) in cluster CL(2) of the 
track data file (1) shown in Figs. 27(A) and 27(B). As 
mentioned above, in each cluster the block encryption 
initial value IV is arranged as the 8 bytes immediately 
before the first sound unit SU (0). Thus, each divided 
cluster contains its own encryption information, so that 
regardless of subsequent division, the data can be eas- 
ily reproduced. 

[0158] The content key data, part key data, and 
block key data of track data file (1) before the division 
are CK-1, PK-1, and BK-1. Further, the content key 
data, part key data, and block key data of track data file 
(1) after division are CK-r. PK-1\ and BK-1. Also, the 
content key data, part key data, and block key data of 
track data file (2) are CK-2. PK-2. and BK-1 . 
[01 59] Figure 30 is a flowchart explaining creation 
of the content key data and the part key data of new 
track data file (2) in editing module 44 of portable player 
4. The new track data file (2) created by the division has 
the new content key data CK-2 separate from the track 
data file (1). By calculating the part key data PK-2 as 
shown below, the block key data BK-1 is the same as 
before the division. The process continues as follows. 
[0160] Step S90: Editing module 44 waits until it 
receives a division Instruction in which case control 
passes to step 891. 

[P161] Step 891: Random number generation unit 
60 generates a random number and creates the new 
content key data CK-2 according to the generated ran- 
dom number. 

[0162] Step 892: Encrypting/decrypting unit 54 of 
portable storage device 3 encrypts the content key data 
CK-2 created at step 891 using the storage use key 
data Skm stored in storage unit 51. 
[0163] Step 893: Editing module 44 writes the 
encrypted content key data CK-2 into the TRKINF in the 
corresponding track data file. 

[0164] Step 894: Editing module 44 creates the 
part key data PK-2 of track data file (2) based on equa- 
tion (15). 

PK-2 = CK-1 XOR PK-1 XOR CK-2 (15) 

[01 65] This process makes the temporary key data 
(from equation (11)) for track data file (2) the same as 
the temporary key data of track data file (1), and the 
cluster key data created (from equation (12)) the same 
as the block key BK-1 before the division. For this rea- 
son, it is not necessary to encrypt the sound units SUs 
in the track data file (2) again using the new block key 
data. 

[01 66] Step S95: Editing module 44 writes the part 
key data PK-2 created at step 894 into PRTINF in the 
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corresponding track data file. 

[0167] Thu8. even when the new content key data 
CK-2 is the same as the content key data of the newly 
created track data file (2) the part key data PK-2 created 
based on equation (15) allows the temporary key data s 
to be made the same as the tenrporary key data before 
the division. As a result, the block key data is also the 
same as before the division. Therefore, it is not neces- 
sary to encrypt the sound units SUs in track data file (2) 
again using the new cluster key data. Similarly, the part io 
key data PK-1 ' of track data file (1) after division is deter- 
mined according to the content key data CK- 1 , so as 
not to change the block key data BK-1 . As a result, it Is 
not necessary to encrypt the sound units SUs in track 
data file (1) after division again by using new block key is 
data. This allows the divisional editing of a track data file 
while avoiding a great increase in the amount of 
processing. Although the above description relates only 
to the track data files IOIq to 101 3, editing module 44 
rewrites the reproduction management file in a corre- 20 
sponding manner. 

[0168] Figure 31 explains coupling (or merging) of 
two track data files by editing module 44 of portable 
player 4. For example, editing module 44 couples track 
data file (1) shown in Figure 3 1 (A) and track data file (2) 2s 
shown in Figure 31 (B) to create track data file (3) shown 
In Figure 31(C). By coupling, a new track data file (3) is 
created containing a part (1) comprised of track data file 
(1) prior to coupling and a part (2) comprised of track 
data file (2) prior to coupling. 30 
[0169] Further, content key data CK-3 for track data 
file (3), part key data PK-3-1 for part (1) and part key 
data PK-3-2 for part (2) are newly created as will be 
explained in greater detail below. The newly created key 
data are set into TRKINF and PRTINF in track data file 3S 
(3). 

[0170] The clusters CL(0) and CL(4) of track data 
file (1) prior to coupling become the start cluster and 
end cluster of part (1 ) of track (3) after coupling. Further, 
the clusters CL(0) and CL(5) of track data file (2) prior to 40 
coupling become the start cluster and the end cluster of 
part (2) of track (3) after coupling. 
[0171] Figure 32 is a flowchart explaining creation 
of the part key data for parts (1) and (2) of the newly cre- 
ated track data file (3). In the following explanation track 45 
data file (1) uses content key data CK-1 , part key data 
PK-1 , and block key data BK-1 . while track data file (2) 
uses content key data CK-2, part key data PK-2. and 
block key data BK-2. Track data file (3) acquires the new 
content key data CK-3 by calculating the part key data so 
of parts (1) and (2) as will be described below. The block 
key data BK-1 and BK-2 remains the same as before 
coupling. The coupling process proceeds as follows. 
[0172] Step S100: Editing module 44 waits until it 
receives a coupling instruction in which case control ss 
passes to step S101. 

[0173] Step S101 : Random number generation unit 
60 generates a random number and creates the content 



key data CK-3 accordingly 

[01 74] Step SI 02: Encrypting/decrypting unit 54 of 
portable storage device 3 encrypts the content key data 
CK-3 created at step SI 01 using the storage use key 
data Skm stored in storage unit 51 . 
[0175] Step S103: Editing module 44 writes the 
encrypted content key data CK-3 into TRKINF off track 
data file (3). 

{0176] Step SI 04: Editing module 44 creates the 
part key data PK-3-1 for part (1) of track data file (3) 
based on equation (16). 

PK-3-1 =CK-1 XOR PK-1 XOR CK-3 (1 6) 

Temporary key data of part (1) (from equation (11)) is 
therefore the same as the temporary key data of the 
track data file (1) prior to coupling. As a result, the block 
key data of part (1) (from equation (12)) is also the same 
as the block key data BK-1 of the track data file (1) prior 
to coupling. Thus, it is not necessary to encrypt the 
sound units SUs of part (1) again using the new block 
key data. 

[0177] Step S105: Editing module 44 creates the 
part key data PK-3-2 for part (2) of track data file (3) 
based on equation (17). 

PK-3-2 = CK-2 XOR PK-2 XOR CK-3 (1 7) 

Temporary key data of part (2) is therefore the same as 
the temporary key data of the track data file (2) As a 
result, the block key data of part (2) is also the same as 
the block key data BK-2 of track data file (2). For this 
reason, it is not necessary to encrypt the sound units 
SUs of part (2) again using the new block key data. 
[0178] Step SI 06: Editing module 44 writes the part 
key data PK-3-1 created at step SI 04 in PRINTF of part 
(1) of track data file (3). 

[01 79] Step S107: Editing module 44 writes the part 
key data PK-3-2 created at step SI 05 in the PRINTF of 
part (2) of track data file (3). 

[0180] Thus, even when the new content key data 
CK-3 is the same as the content key data of the newly 
created track data file (3), the part key data PK-3-1 and 
PK-3-2 created based on the equations (16) and (17) 
allows the temporary key data for each part to be made 
the same as for the similar data before the coupling. As 
a result, the block key data of the corresponding parts is 
also the same as BK-1 and BK-2 before the coupling. 
Therefore, it is not necessary to encrypt the sound units 
SUs in parts (1) and (2) again, using the new block key 
data. For this reason, the great increase in the amount 
of processing which normally accompanies coupled 
editing is avoided. Further, although the above descrip- 
tion only relates to the track data files 1 01 0 to 101 3, edit- 
ing module 44 correspondingly rewrites the 
reproduction management file ICQ. 
[0181] The present invention is not limited to the 
above embodiments. For example, the above embodi- 
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merits have the number of bytes {160 bytes) of the 
sound units SUs a whole multiple of the number of bytes 
(8 bytes) of the cipher block (the unit of encryption in the 
CBC mode). But the present invention, can be adjusted 
for when rt is not a whole multiple by inserting padding 5 
to adjust the data length of the sound unit SU. 

[0182] Further, the case was shown of first output- 
ting the random number R„,5 created at portable stor- 
age device 3 to portable player 4 when mutual 
identification processing is performed as shown in Fig- 10 
ure 22. But it is also possible to first output a random 
number created at portable player 4 to portable storage 
device 3. 

[0183] Further, the case where 32 sets of the iden- 
tification key data and master key data were stored in 75 
storage units 51 and 61 was shown, but there may be 
any number of these sets as long as it is 2 or more. 
[0184] Further, the case where the identification key 
data IKq to ll^i were created from the master key data 
MKoto MK31 in portable player 4 was given. But it is also 20 
possible to store the identification key data IKq to IKg^ in 
portable player 4 in the same way as that for portable 
storage device 3 and select the identification key data 
according to the random number Rj. 
[0185] Further, as shown in Figure 21, the case 25 
where the identification key data IKj and the master key 
data MKj are selected in potable storage device 3 and 
portable player 4 by using the random number Rj cre- 
ated at portable player 4 was exemplified. But it is also 
possil3le to use a random number created at portable so 
storage device 3 or to use random numbers generated 
in both portable storage device 3 and portatile player 4. 
[0186] Further, the above embodiments show the 
case where the identification key data IKj and the mas- 
ter key data MKj were selected In portable storage 3S 
device 3 and portable player 4 based on the random 
number Rj. But according to the present invention, it is 
also possible to input the 5-bit key selection instruction 
data to portable storage device 3 and portable player 4 
from the outside and select the identification key data 40 
IKj and the master key data MKj corresponding to each 
other indicated by the related key selection instruction 
data at portable storage device 3 and portable player 4. 
[0187] Further, an example was given of data con- 
taining audio data as the track data, but the present 45 
invention can also be applied where track data contain- 
ing moving picture data, stationary image data, docu- 
ment data, program data, and other types of data are 
stored in flash memory 34. 

[0188] As explained above, according to the data so 
processing apparatus and the data processing system 
of the present invention and the method for the same, 
even in the case where the first key data is changed 
after encrypting the track data by using the third key 
data and storing the same in the storage device, the ss 
third key data is not changed, so it becomes unneces- 
sary to decrypt and re-encrypt the track data. For this 
reason, the amount of processing required when the 



first key data is changed is greatly reduced. 
[01 89] It will thus be seen that the objects set forth 
above, among those made apparent from the preceding 
description, are efficiently attained and. because certain 
changes may be made in carrying out the above 
method and in the construction(s) set forth without 
departing from the scope of the invention, it is intended 
that all matter contained in the above description and 
shown in the accompanying drawings shall be inter- 
preted as illustrative and not in a limiting sense. 
[01 90] h is also to be understood that the following 
claims are intended to cover all of the generic and spe- 
cific features of the invention herein described and all 
statements of the scope of the invention which, as a 
matter of language, might be said to fall therein. 
[01 91 ] In so far as the embodiments of the invention 
described above are implemented, at least in pat using 
software-controlled data processing apparatus, it will be 
appreciated that a computer program providing such 
software control and a storage medium by which such a 
computer program is stored are envisaged as aspects 
of the present invention. 

Claims 

1 . A data processing apparatus comprising: 

encrypting means for encrypting data in units 
of an encryption block having a predetermined 
data length; 

processing means for performing predeter- 
mined processing on data in units of a process- 
ing block having a data length of a whole 
multiple of said predetermined length of said 
encryption block; 

storage means for storing the encrypted data; 
and 

control means for writing the encrypted data in 
said storage means so that the data positioned 
in the same encryption block is also positioned 
in the same processing block, said control 
means reading the data from said storage 
means in units of the processing block. 

2. The data processing apparatus as set forth in claim 
1, wherein said control means inserts data into said 
processing block to adjust the data length in the 
processing block so that the length of sakJ process- 
ing block becomes a whole multiple of the predeter- 
mined data length of said encryption block 

3. TTie data processing apparatus as set forth in claim 
1, wherein said encrypting means performs enayp- 
tion processing using the encryption block to be 
encrypted and a cipher text obtained from the 
encryption of the encryption block immediately prior 
to the encryption block to be encrypted. 
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4. The data processing apparatus as set forth in claim 

3, wherein said control means manages the 
encrypted data stored in said storage means using 
a cluster containing one or more processing blocks 
and values initially used when encrypting an 5 
encryption block in one of said processing blocks. 

5. The data processing apparatus as set forth In claim 

4, wherein said control means stores said one or 
more processing blocks at consecutive addresses 10 
of said storage means in the order of encryption, 
stores said one or more encryption blocks in said 
processing blocks at consecutive addresses of said 
storage means in the order of encryption, and 
stores said initial values at an address immediately is 
prior to the address of at which the first encryption 
block in the cluster is stored. 

6. The data processing apparatus as set forth in claim 

1, wherein said control means outputs said data 20 
read out in processing block units to said process- 
ing means. 

7. The data processing apparatus as set forth in claim 

6, wherein said data is compressed; and 2s 

said processing means expands the data read 
from said storage means in units of a process- 
ing block. 

30 

8. A data processing system for inputting and output- 
ting data while performing mutual Identification 
between a storage apparatus and a data process- 
ing apparatus, said storage apparatus comprising: 

35 

first mutual identification processing means for 
performing processing for mutual identification 
with said data processing apparatus; 
storage means for storing said data; and 
first control means for allowing the input and 40 
output of data between said data processing 
apparatus and said storage means when said 
data processing apparatus is recognized to be 
a legitimate party by the processing for mutual 
identification; 45 
said data processing apparatus comprising: 
second mutual identification processing means 
lor performing processing for nfujtual identifica- 
tion with said storage apparatus; 
encrypting means for encrypting data in units so 
of an encryption block of a predetermined data 
length; 

processing means for performing predeter- 
mined processing on said data in units of a 
processing block having a data length that is a ss 
whole multiple of the predetermined data 
length of the encryption block; and 
second control means for performing at least 



one of write processing and read processing 
when said data processing apparatus rs recog- 
nized to be a legitimate party by the processing 
for mutual identification, fbr writing the 
encrypted data in said storage means so that 
data positioned in one encryption block is also 
positioned in the same processing block during 
write processing, and for reading the data from 
saki storage means in units of a processing 
block during read processing. 

9. The data processing system as set forth in claim 8. 
wherein said second control means inserts data 
into saki processing block to adjust the data length 
in the processing block so that the length of said 
processing block becomes a whole multiple of the 
predetermined data length of said encryption block. 

10. The data processing system as set forth in claim 8. 
wherein said encrypting means performs encryp- 
tion processing using the encryption block to be 
encrypted and a cipher text obtained from the 
encryption of the encryption block immediately prior 
to the encryption block to be encrypted. 

11. The data processing system as set forth in daim 

10, wherein said second control means manages 
the encrypted data stored in said storage means 
using a cluster containing one or more processing 
blocks and values initially used when encrypting an 
encryption block in one of said processing blocks. 

12. The data processing system as set fortii in daim 

1 1 , wherein the second control means stores sakd 
one or more processing blocks at consecutive 
addresses of saki storage means in the order of 
encryption, stores said one or more encryption 
blocks in said processing blocks at consecutive 
addresses of said storage means in the order of 
encryption, and stores said initial values at an 
address immediately prior to the address of at 
which the first encryption block in the cluster is 
stored. 

1 3. A data processing method, comprising the steps of: 

encrypting data in units of an encryption block 
having a predetermined data length; 
performing predetermined processing on said 
data in units of a processing block having a 
data length that is a whole multiple of the pre- 
determined data length of the encryption block; 
writing the encrypted data to a storage means 
so that all of the data positioned in one encryp- 
tion block is also positioned in the same 
processing block; and 

reading the data from the storage means in 
units of the processing block. 
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14- The data processing method as set forth in claim 
13, further comprising the step of inserting data into 
said processing block to adjust the data length in 
the processing block so that the length of said 
processing block becomes a whole multiple of the s 
predetermined data length of said encryption block. 

15. The data processing method as set forth in claim 
13. further comprising the step of using the encryp- 
tion block to be encrypted and a cipher text io 
obtained from the encryption of the encryption 
block immediately prior to the encryption block to 

be encrypted to perform encryption processing. 

16. The data processing method as set forth in claim is 

15, further comprising the step of managing the 
encrypted data stored in said storage means using 
a cluster containing one or more processing blocks 
and values initially used when encrypting an 
encryption block in one of said processing blocks. 20 

17. The data processing method as set forth in claim 

16, further comprising the steps of: 

storing said one or more processing blocks at 2s 
consecutive addresses of said storage means 
in the order of encryption; 
storing said one or more encryption blocks in 
said processing blocks at consecutive 
addresses of said storage means in the order 30 
of encryption; and 

storing said initial values at an address immedi- 
ately prior to the address of at which the first 
encryption block in the cluster is stored. 

35 

18. The data processing method as set forth in claim 
13. further comprising the step inserting data into 
said processing block to adjust tiie data length in 
the processing block so that the length of said 
processing t)lock becomes a whole multiple of the 4o 
predetermined data length of said encryption block. 
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